Tag Archives: yazılım geliştirme

Lessons Learned in Software Development

21 Nis


1. Start small, then extend. Whether creating a new system, or adding a feature to an existing system, I always start by making a very simple version with almost none of the required functionality. Then I extend the solution step by step, until it does what it is supposed to. I have never been able to plan everything out in detail from the beginning. Instead, I learn as I go along, and this newly discovered information gets used in the solution.

I like this quote from John Gall: “A complex system that works is invariably found to have evolved from a simple system that worked.”

2. Change one thing at a time. When you develop, and some tests fail, or a feature stops working, it’s much easier to find the problem if you only changed one thing. In other words, use short iterations. Do one thing, make sure it works, repeat. This applies down to the level of commits. If you have to refactor the code before you add a new feature, commit the refactoring first, then (in a new commit) add the new feature.

3. Add logging and error handling early. When developing a new system, one of the first things I do is adding logging and error handling, because both are useful from the very beginning. For all systems that are bigger than a handful of lines of code, you need some way of knowing what happens in the program. Perhaps not when it is working as expected, but as soon as it doesn’t, you must be able to see what’s happening. The same goes for error handling – errors and exceptions happen in the beginning too, so the sooner you handle them in a systematic way, the better.

4. All new lines must be executed at least once. Before you are done with a feature, you have to test it. Otherwise, how do you know that it does what it is supposed to do? Often, the best way is by automatic tests, but not always. But no matter what, every new line of code has to be executed at least once.

Sometimes it can be hard to trigger the right conditions. Fortunately, it’s easy to cheat a bit. For example, the error handling on a database call can be checked by temporarily misspelling a column name. Or, an if-statement can be temporarily inverted (“if error” becomes “if not error”) in order to trigger something that rarely happens, just to make sure that code is run and does what it should.

Sometimes I see bugs that show that a certain line of code can never have been run by the developer. It can look fine when reviewed, but still not work. You avoid embarrassment if your policy is to always execute every new line you write.

5. Test the parts before the whole. Well-tested parts save time. Often there are problems with integrating different parts, for example from mismatched or misunderstood interfaces between modules. If you can trust that the parts work as expected, it becomes much easier to track down the integration problems.

6. Everything takes longer than you think. Especially in programming. It is hard to estimate how much time a feature will take even if everything goes smoothly. But when developing software, it is quite common to run in to unexpected problems: a simple merge turns out to cause a subtle bug, an upgrade of a framework means some functions must be changed or an API call doesn’t work as promised.

I think there is a lot of truth in Hofstadter Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

7. First understand the existing code. Most coding requires changing existing code in some way. Even if it is a new feature, it needs to fit into the existing program. And before you can fit the new stuff in, you need to understand the current solution. Otherwise you may accidentally break some of the existing functionality. This is means that reading code is a skill that is as necessary as writing code. It is also part of the reason why seemingly small changes can still take a long time – you must understand the context in which you make the change.

8. Read and run. Fortunately, there are two complementary methods for understanding code. You can read the code, and you can run the code. Running the code can be a great help when figuring out what it does. Be sure to make use of both methods.


9. There will always be bugs. I don’t like approaches to software development that claim to “get it right the first time”. No matter how much effort you put in, there will always be bugs (the definition of a bug pretty much is: “we didn’t think of that”). A much better approach is to have a system in place that lets you quickly troubleshoot problems, fix the bugs and deploy the fixes.

10. Solve trouble reports. Every developer should spend a portion of their time handling trouble reports from customers and fixing bugs. It gives you a much better understanding of what the customers are trying to do, how the system is used, how easy or hard it is to troubleshoot and how well the system is designed. It’s also a great way of taking responsibility for what you develop. Don’t miss out on all these benefits.

11. Reproduce the problem. The first step when fixing a bug is to reproduce the problem. Then you make sure that when the fix is added, the problem is gone. This simple rule makes sure you are not assuming something is a problem when it isn’t, and makes sure the solution actually does what you think it does.

12. Fix the known errors, then see what’s left. Sometimes there are several problems present that you know about. The different bugs can interact with each other and cause strange things to happen. Instead of trying to work out what happens in those cases, fix all the know problems and then see what symptoms remain.

13. Assume no coincidences. When testing and troubleshooting, never believe in coincidences. You changed a timer value, and now the system restarts more often. Not a coincidence. A new feature was added, and an unrelated feature becomes slower? Not a coincidence. Instead, investigate.

14. Correlate with timestamps. When troubleshooting, use the timestamp of events as a help. Look for even increments. For example, if the system restarted, and a request was sent out around 3000 milliseconds before, maybe a timer triggered the action that lead to the restart.


15. Face to face has the highest bandwidth. When discussing how to solve a problem, being face to face beats video, call, chat and email. I am often amazed at how much better the solutions are after discussing them in person with colleagues.

16. Rubber ducking. Whenever you are stuck, go to a colleague and explain the problem to them. Many times, as you talk, you realize what the problem is, even if your colleague doesn’t say a word. Sounds like magic, but works surprisingly often.

17. Ask. Reading and running the code is often great for figuring out what it does and how it works. But if you have the possibility to ask someone knowledgeable (perhaps the original author), use that option too. Being able to ask specific questions, and follow-up questions to those, can give you information in minutes that would otherwise take days to get.

18. Share credit. Make sure to give credit where credit is due. Say: “Marcus came up with the idea to try…” (if he did), instead of “we tried …”. Go out of your way to mention who else helped or contributed.


19. Try it. If you are unsure of how a certain language feature works, it is easy to write a little program that shows how it works. The same applies when testing the system you are developing. What happens if I set this parameter to -1? What happens if this service is down when I reboot the system? Explore how it works – fiddling around often reveals bugs, and at the same time it deepens your understanding of how the system works.

20. Sleep on it. If you are working on a difficult problem, try to get in a night’s sleep before you decide. Then your subconscious mind works on the problem even when you aren’t actively thinking about it. As a result, the solution can seem obvious the next day.

21. Change. Don’t be afraid to change roles of jobs every once in a while. It is stimulating to work with different people, on a different product or in a different company. In my view, too many people just passively stay at the same job year after year, only changing if they are forced to.

22. Keep learning. One of the great things with software development is that there is always room to learn and know more. Try out different programming languages and tools, read books on software development, take MOOC courses. Small improvements soon add up to make a real difference in your knowledge and abilities.

Kaynak: http://henrikwarne.com/2015/04/16/lessons-learned-in-software-development/


Herkes için Yazılım Geliştirme Açıklaması

11 Haz

Uygulama Türleri

 Masaüstü Uygulamalar, lokal olarak masaüstü bilgisayarlara kurulum gerektirerek kullanılan, offline çalışabilen, yapısına göre internete çıkabilen ve kendi verilerini lokalindeki bir veritabanında tutabilen uygulamalardır.

 Web Uygulamaları, İnternet tarayıcıları (IE,FireFox,Chrome) üzerinde çalışabilen internet ortamında herhangi bir sunucuda Host edilerek hizmet ettirilebilen uygulamalardır.Browser’ın çeşidine veya browser’ın çalıştığı ortama yani mobil veya PC’ye göre yazılım özellikleri değişebilmektedir.

 Mobil Uygulamalar, Android, Windows Phone ve IOS gibi mobil işletim sistemlerine kurulabilen, uygulama verilerini lokalde; mobil cihazda tutarak Offline çalışabilen ve gereksinime göre internet bağlantısı kullanabilen uygulamalardır.


Yazılım Geliştirme Dilleri

ASP.NET, Microsoft tarafından geliştirilmiş bir web uygulama gelişimi teknolojisidir. Dinamik web sayfaları, web uygulamaları ve XML tabanlı web hizmetleri yaratılmasına olanak sağlar. Geliştiriciler .Net çatısı tarafından desteklenen tüm dilleri (C#, Visual Basic) ASP.NET uygulamaları geliştirmek için kullanabilirler. Yani, Java teknolojisinde olduğu gibi, yazılımcı tarafından yazılan kod, çalıştırılmadan önce sanal bir yazılım katmanı tarafından ortak bir dile çevrilmektedir.

JAVA, Sun Microsystems (Oracle Satın Almıştır) tarafından geliştirilmeye başlanmış açık kodlu, nesneye yönelik, ortam bağımsız, yüksek verimli, çok işlevli, yüksek seviye bir dildir.

 Diğer Diller, SAP’nin ABAP’ı, teknolojisi eski kalmış Delphi,C veya embeded (gömülü) cihaz (Modem-Uydu Alıcısı) yazılımlarında yaygın kullanılan C++ gibi diller de vardır.


 Yazılım Geliştirme Ortamları

 Microsoft Visual Studio, .NET dillerinin geliştirme ortamıdır. (IDE) Bu ürün yazılımcısının hazır bir arayüzden yazılım arayüzlerini sürükle bırakla oluşturmasını ve arka planına kod yazarak yazılımı programlamasını sağlar.

 Eclipse, Java ve Phyton gibi yazılım dilleri için açık kaynak kodlu geliştirme ortamıdır. Çalışma mantığı Visual Studio ile benzerdir.

 Diğer, farklı yazılım dilleri veya geliştirme yapılan ortamlar için değişik geliştirme platformları vardır.

Web yazılımlarının çalışması için Sunuculara sahip olmak gerekmektedir. Sunucular fiziksel olarak çalışma bilgisayarlarımızdan(PC) üstün özelliklere sahip özel sunucu işletim sistemlerine sahip makinalardır. Windows, Unix ve Linux vb.. tipinde sunucular piyasada bulunmaktadır.



 Microsoft SQL Server, Microsoft’un veritabanı ürünüdür. Maliyet avantajı ve kullanım kolaylığı sebebiyle tercih edilir. Veritabanı yapısı olarak barındırdığı tablolarda alan bazında verilerin tutulmasını sağlar.

 Oracle, Oracle şirketinin kendi adını taşıyan veritabanı ürünüdür. Maliyetlidir fakat performans ve veri yükü bakımından daha iyi olduğu kabul edildiği için tercih edilir. Veritabanı veri saklama ve erişme yapısında farklılıklar vardır.

Yazılımcılar veritabanı markasından bağımsız yazılım geliştirebilmektedir. Fakat bazı özel geliştirme modellerinde sistemlerin uyumlu olması önem taşımaktadır.


Yazılım Geliştirme Süreci

Geliştiricinin nasıl bir yazılım (Program) geliştireceğini bildiğini varsayarak süreci anlatacak olursak;

v  Geliştirici uzmanlaştığı yazılım dilini seçecektir (Java veya .NET(ASP.NET,C#))

v  Geliştirme ortamını seçerek geliştirmeye başlayacaktır. (Visual Studio veya Eclipse veya Diğerleri)

v  Geliştirici örnek verdiğimiz popüler ve modern dillerden birini seçtiğinde Nesneye yönelimli denilen hızlı, kolay ve tutarlı kod yazmasını sağlayan teknolojiyi seçmiş olacaktır.

v  Geliştiricinin üslubuna göre geliştirme katmanlı mimariye uygun geliştirilebileceği gibi tek bir düzende de geliştirme yapılabilmektedir.

v  Geliştiriciler çalışırken yazılım dilinin sunduğu hazır veya kolaylık sunan Kütüphane, Metod, Sınıf, Framework gibi yapıları kullanabilmektedir.

v  Geliştirici yine bir çok tasarım nesnesi için Component denen hazır nesne ürünlerini yazılımında kullanabilmektedir.

v  Yine geliştirici yazılımında veritabanlarına bağlanmak için adaptör denen yapıları kullandığı gibi başka sistemlerle iletişim sağlamak için API denen yazılım parçalarını veya Web servis denen iletişim protokollerini kullanabilmektedir.

v  Özetle geliştirici gereksinim duyduğu Framework ve kütüphaneleri yazılımına altyapı kabul edebilmekte, katmanlı mimariyle kodlarını işlevlerine göre ayrı sayfalarda yazabilmekte, Gereksinimine göre entegrasyon için API ve Web servisler kullanabilmektedir.


Yazılım geliştirme sürecinde çok değişik süreçler, mimariler ve desenler uygulanabilmektedir. Bu değişiklikler geliştirme gereksinimine, geliştirici profiline, teknolojilerine ve diğer öncelik konularına bağlı olarak değişebilmektedir.

Yazılım geliştirme işlemleri tamamlandığında yazılan kodlar ve her türlü geliştirme unsuru geliştirme ortamlarında derlenerek kullanıma hazır hale getirme aşamasından geçirilmektedir.

Derlenen ve hazırlanan yazılımlar eğer Masaüstü yani PC uygulaması veya Mobil uygulama ise işletim sisteminde kurulumu yapılarak kullanıma açılabilir. Yazılım web yazılımı ise bu yazılımı internette servis edecek sunucuya yazılımın deploy edilmesi ve gerekli konfigürasyon ayarıyla erişilecek adresden yazılımın servis edilmesi sağlanmalıdır.